Governmental regulatory bodies, courts, and laws required that certain communications be preserved and require that organizations and individuals respond to certain communications in prescribed manners. For example, an insurance company may be required to log (and potentially respond to) all instances in which a litigation threat is made to an insurance broker in relation to a policy written by the insurance company, even if the broker is not employed directly by the insurance company, but is an independent contractor representing multiple insurance companies. In another example, a company involved in litigation may be required to produce all communications to or from a particular employee or type of employee. In another example, a company may be required to handle credit card information in ways prescribed by contract and/or law, such as that credit card information be encrypted and/or that it not be held for longer than a specified period of time. In the United States, Sarbanes Oxley, HIPAA, the Data Protection Act, the Patriot Act, and other laws require that certain communications be preserved, sometimes in different ways (such as with different security levels) and/or responded to in different ways. Hereinafter, the term “monitored user” will refer to a party whose communications need to be journaled and archived; the monitored user may be a party such as the broker discussed above, an employee of a company, or similar.
Various service providers and software companies have begun to address the need to journal and archive electronic communications, such as email, and one-to-one or one-to-many instant messaging. However, many such solutions require that the email and/or instant messaging take place on computers under the control of the company with the journaling need and/or under the control of a journaling service provider. For example Microsoft, Inc., released an email journaling feature in service packs for Exchange™ dating back to 2000, 2003, and 2004. As is typical, the feature requires that rules be set to determine which emails should be journaled, rules based on a sender or recipient. Journaling and archiving systems commonly operate at the email server by copying a journaled message to a new email (often as an attachment), preserving the journaled message's original headers in the message body of the new email (if an email is merely forwarded by an email client, the original headers are often discarded or modified), optionally utilizing different protocols to record bcc recipients, recipients from distribution groups, and recipients who result from forwarding rules, and sending the new journal email to a journaling server and/or archive server. These systems represent a problem relative to the example provided in the preceding paragraph with respect to the insurance company broker who, as an independent contractor, may be using an email service not controlled by the insurance company. Steps may be taken to forward the email from the broker's site to the insurance company or a journaling/archiving service provider, though these steps assume that the broker controls the broker's email server, which may not be the case, and/or such an approach may result in forwarding too many emails to the journaling/archiving service provider, such as forwarding all of the broker's email and/or email from others at the broker's location which may meet the forwarding criteria. In addition, existing journaling and archiving systems do not address communications which take place in social media. Social media present a different set of problems in terms of identifying which and how communications are to be journaled/archived, accessing the social media providers, and maintaining access to the social media providers in a way which is not taxing to the monitored user.
In addition, a journaling/archiving service provider may find that an email to be journaled and archived needs to be sent to multiple journal and archive destinations, such as if the monitored user represents a company with multiple journaling and archiving destinations or if the monitored user represents more than one company, each of which may have multiple journaling and archiving destinations. For example, FIG. 3 (not showing prior art) presents a diagram of a monitor 305. The monitor 305 may be engaged by one or more monitor customers 303 to monitor the communications sent and received by the monitored users 301.A through 301.C from communicators 105.A through 105.C (who may be anyone the monitored users 301 communicate with, including the monitor customer 303 and others). The monitor 305 may maintain its own journal servers 221 and archives 223 to journal and archive monitored communications; the monitor customer 303 may also require that communications be sent to a 3rd party monitor 307, separate from the monitor 305; the 3rd party monitor may maintain journal servers and archives (not shown) or may perform other operations with respect to monitored communications, such as (for example) indexing content to improve a search algorithm. The multiple archives 223.A through 223.C and archives and/or other processors of the 3rd party monitor 307 may utilize different formats, may have different security requirements, or generally have different structures. In this case, the multiple journaling and archiving destinations may accept the message to be journaled in different formats.
In existing approaches, multiple journaling and archiving systems must be setup separately to address the monitored users 301. In addition, the monitor 305 would not handle social media. In addition, different journaling and archiving systems maintained by monitor 305 and 3rd party monitor 307 do not work together.
In the context of email, emails generally have a structure comprising an envelope, one or more headers, a message body (or simply “body”), and attached messages. Email format is generally described in Request for Comments (“RFC”) 5322, published by the Network Working Group of the Internet Engineering Task Force (“IETF”), with additional information in RFC 5321, Simple Mail Transfer Protocol (“SMTP”). The envelope generally contains addressing information which is used by email servers to route the email, generally the “to” address and a “from” or “on behalf of” address. The header generally contains addressing and additional information (such as subject and date/time), though the header information is not necessarily used by email servers to route the email. The message body generally contains text in ASCII format. Email attachments are generally in a Multipurpose Internet Mail Extensions (“MIME”) format, which makes possible text in character sets other than ASCII (including for use in supporting non-ASCII header information), non-text data attachments, message bodies with multiple parts, and as otherwise specified in the following RFCs: 2045, 2046, 2047, 4288, 4289, and 2049. As used herein, emails are discussed as comprising an outer message comprising an envelope, header, body, and attachments (if any), as well as potentially comprising an inner message. The inner message may comprise the same parts (envelope, header, body, and attachments), though the envelope of the inner message is not generally used to route the inner message. The inner message is carried in the message body of the outer message or as an attachment to the outer message. The inner message is not routed separately from the outer message (which is routed). The inner message is an email message which is attached to or made part of (the body of) the outer message.
An email journal message or journal message is an outer email message which includes an inner message comprising content from a new email message. The journal message (including both outer and inner parts) may be journaled, analyzed and archived, while the new message (just the inner part of the email journal message) is sent (separately from the email journal message) to the intended recipient. In addition to the inner message comprising content from the new email message, the journal message may contain metadata related to the new message, such as times, dates, names/physical location of/identifiers for individuals involved in the communication, and/or a class or category assigned to the message by a person or by rules executed by a software program. The journal message generally follows an email transport format, such as SMTP, and is sent as an email to an email journal server. The journal message may be encrypted and/or may not be accessible to the end-user who generated the new email message which was journaled. The journal message may be handled as an email by existing communication infrastructure.
Archiving generally refers to backing up a communication, often to an off-site location or to files not actively used by an end user's email client. A journaling system may be used as an interface to an archival system.
Recently, social media (such as Facebook, Twitter, and similar) have become widely used as communication forums. Social media present many challenges in the context of journaling and archiving communications, including that authorization is required from the social media forum to perceive the communication, that social media authentication and authorization systems change frequently, that the presentation of communications to users within a social media context may depend on a host of factors (there is not necessarily a “sender” and a “recipient”), and that a wide range of communication modes are possible, including video, photographs, text exchanges taking place across short or long time frames, communications composed of content from multiple contributors selected by the social media operator and advertisers, and communications directed algorithmically at groups, rather than from one individual to another or through broadcasts.
Needed is a communication journaling and archiving system which i) obtains specified content from a social media network, re-authenticates with the social media network as necessary, ii) stores email, instant message, and content from social media networks in a system compatible with email journaling and archiving systems, and iii) can be configured to send a journaled communication to multiple journal destinations and journal formats.